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Abstract  -  In  order  to  have  autonomous  formation-flying 
satellite  constellations  in  low  earth  orbit  (LEO),  the  satel¬ 
lites  in  the  constellation  must  be  able  to  communicate 
with  each  other  directly  via  intersatellite  links  (ISLs). 
Current  ISL  implementations  use  lower  layer  link  proto¬ 
cols  based  on  existing  networking  protocols  such  as  X.25 
and  LAP-B,  which  were  not  designed  specifically  for  ISL 
use.  This  paper  compares  current  and  upcoming  lower 
layer  protocols  in  an  attempt  to  identify  a  protocol  for 
widespread  ISL  use  such  that  interaction  among  differ¬ 
ent  constellations  is  possible  and  the  addition  of  new  sat¬ 
ellites  to  existing  constellations  is  simpler. 

1.0  Introduction 

Recent  advances  in  micro  electro-mechanical  systems 
(MEMS)  permit  robust  microsatellites  to  be  built.  The  com¬ 
bined  resources  of  several  of  these  smaller,  smarter  satellites 
for  applications  such  as  distributed  aperture  remote  sensing, 
has  significant  scientific,  performance  and  cost  advantages 
over  using  large,  heavy,  single-mission  satellites.  In  order  to 
effectively  combine  the  resources  of  autonomous,  formation¬ 
flying  constellations  of  smaller  satellites,  the  satellites  must 
have  the  ability  to  communicate  with  each  other. 

Autonomy  implies  minimal  dependence  on  ground  stations 
for  communication  purposes,  and  so  intersatellite  links 
(ISLs)  must  be  used  to  allow  satellites  to  share  their  individ¬ 
ual  information  and  use  their  combined  resources  to  achieve 
a  more  complex  goal.  Selecting  the  lower  layer  protocols  for 
use  with  an  ISL-based  communication  system  demands  a 
comparison  of  system  requirements  against  the  functionality 
of  existing  standards.  Using  an  existing  standard  is  simplest 
in  terms  of  cost  and  time.  However,  standards  currently  used 
in  similar  applications  for  ISLs  are  based  on  terrestrial  net¬ 
working  protocols  developed  over  a  decade  ago  and  are  not 
necessarily  optimized  for  short  range  space  links.  Modifica¬ 
tions  to  optimize  existing  protocols  for  use  in  ISLs  are  not 
simple  and  are  almost  always  proprietary.  This  does  not 
encourage  communication  with  other  nearby  constellations 
or  simplify  adding  new  satellites  to  an  existing  constellation. 

This  work  was  supported  by  the  U.S.  Department  of  Defense  and  the  U.S. 
Air  Force  Office  of  Scientific  Research  under  Contract  F29601-99-C-0029. 


Ligure  1:  Conceptual  depiction  of  autonomous  constellation 
courtesy  of  the  ALRL  TechSat  21  (Technology  Satellite  of 
the  21st  Century)  program. 

This  paper  compares  and  contrasts  existing  standards  such  as 
X.25/LAP-B,  TCP/IP,  ATM,  and  even  the  wireless  IEEE 
802.11  protocol  to  determine  which  best  meets  the  needs  of 
the  ISL  lower  layers  for  an  autonomous  constellation.  The 
comparison  also  includes  a  discussion  of  the  upcoming  Con¬ 
sultative  Committee  for  Space  Data  Systems  (CCSDS)  Prox¬ 
imity- 1  protocol  that  was  created  specifically  for  proximity- 
range  space  links,  and  evaluates  the  CCSDS  Proximity- 1 
stack  against  the  X.25  stack. 

ISL  and  Low  Layer  Protocol  Definition 

Intersatellite  links  are  two-way  communication  paths 
between  satellites.  They  have  the  potential  to  provide  flexi¬ 
bility  in  the  space  segment  implementation  while  maintain¬ 
ing  or  reducing  the  cost  of  the  system’s  earth  segment  [1].  As 
described  in  Section  2,  the  low  layer  protocol  choice  is  a  key 
part  of  ISL  design  for  autonomous  constellations  because  it 
must  guarantee  reliable  transfer.  Reliable  transfer  is  critical 
for  autonomous  constellations  from  a  navigation  and  data 
collection  standpoint.  Messages  must  be  delivered  error-free, 
in  order,  no  duplicates,  and  without  added  delay [2].  Addi¬ 
tional  requirements,  including  data  rate,  range  and  power, 
must  also  be  considered.  Autonomous  constellations  in  gen¬ 
eral  also  require  significant  networking  and  multiple  access 
capability. 
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Types  ofISL  Media  and  Data  Rate  Requirements 

Radio  frequency  (RF)  and  Optical  (laser)  are  the  two  pri¬ 
mary  communication  media  for  an  ISL.  Optical  has  the 
advantage  of  higher  data  rates,  low  probability  of  intercept, 
smaller  size,  and  lower  power.  However,  it  also  has  much 
more  complex  acquisition  and  tracking,  may  have  additional 
delays  in  converting  electrical  signals  to  optical,  and  is  fairly 
new  as  far  as  flight  implementation  is  concerned.  The  current 
advantage  is  with  radio  links  for  throughputs  on  the  order  of 
10Mbps.  Optical  links  may  be  more  advantageous  for 
throughputs  at  several  tens  of  Mbps  or  more  [3].  For  the 
requirements  of  an  autonomous  constellation  of  LEO  micro¬ 
satellites  or  nanosatellites  with  data  rates  currently  on  the 
order  of  1Mbps,  RF  links  are  more  than  adequate. 

ISL  Multiple  Access 

Multiple  access  schemes  require  an  additional  layer  in  the 
low  level  stack  for  media  access  control  (MAC)  which  is  dis¬ 
cussed  in  the  brief  link  layer  outline  in  Section  2.  Use  of  a 
spread  spectrum  link  for  multiple  access  in  an  autonomous 
constellation  is  desirable  as  spread  spectrum  links  can  pro¬ 
vide  resistance  to  intentional  jamming,  mask  the  transmitted 
signal  in  the  background  noise  to  prevent  eavesdropping, 
provide  resistance  to  degrading  and  multipath  effects  on  the 
signal,  and  also  provide  range-measuring  capability.  The  two 
major  types  of  spread-spectrum  systems  are  direct-sequence 
spread  spectrum  (DSSS)  and  frequency-hop  spread  spectrum 
(FHSS).  In  DSSS,  a  spreading  code  with  a  rate  much  higher 
than  the  data  rate  multiplies  the  data  sequence  to  spread  the 
spectrum,  and  for  FHSS,  a  synthesizer  driven  by  a  pseudo¬ 
random  noise  generator  provides  a  carrier  that  changes  fre¬ 
quency  in  a  pseudorandom  manner  [4], 

Using  the  IEEE  802.11  standard  as  a  reference  (with  US 
standards  requiring  <  1W  of  RF  power),  current  implementa¬ 
tions  of  FHSS  achieve  rates  only  up  to  1 -2Mbps.  Current 
implementations  of  DSSS  can  achieve  rates  up  to 
11  Mbps [5].  FHSS  will  get  faster  when  the  cost  of  using  an 
equalization  circuit  to  reduce  inter-symbol  interference  (ISI) 
at  higher  data  rates  goes  down.  FHSS  should  be  used  where 
it  is  desirable  to  avoid  high  power,  narrow  band  interference 
and  the  lower  data  rate  of  a  few  Mbps  is  acceptable  [3].  Sec¬ 
tion  3  will  discuss  IEEE  802.11  in  more  detail. 

ISL  Constellations  and  Low  Layer  Protocols 

When  considering  ISL  low  layer  protocols  for  autonomous 
constellations,  it  is  useful  to  briefly  discuss  existing  non- 
autonomous  satellite  constellations  that  have  successfully 
used  crosslinks. 

Milstar  was  the  first  geostationary  (GEO)  constellation  to 
use  intersatellite  links  and  onboard  processing  to  get  a  short 
message  to  strategic  bomber  pilots  and  missile  commanders 
during  a  nuclear  war.  The  original  spacecraft  were  initially 
large  and  consumed  a  lot  of  power,  but  new  designs  are  sig¬ 


nificantly  smaller  and  more  efficient.  The  first  Milstar  launch 
was  in  1994.  The  first  commercial  test  of  onboard  processing 
and  intersatellite  links  was  Iridium  (LEO)  in  1998. 


Figure  2:  An  artist’s  conception  of  TDRSS. 


Another  well-known  constellation  that  uses  crosslinks  is 
NASA’s  TDRSS  (Tracking  and  Data  Relay  Satellite  Sys¬ 
tem).  TDRSS,  also  GEO,  tracks  and  communicates  with 
Earth-orbiting  spacecraft  such  as  the  International  Space  Sta¬ 
tion  (ISS)  and  the  Hubble  Space  Telescope  (HST)  and  trans¬ 
mits  their  data  to  ground  stations  on  Earth.  It  offers  both 
single  access  and  multiple  access  support  in  downlinking 
data  and  can  handle  a  variety  of  frequency  bands,  but  the 
system  is  not  very  similar  to  an  autonomous,  formation-fly¬ 
ing  constellation  in  terms  of  data  rate,  power  consumption, 
or  size. 

Out  of  the  multitude  of  commercial  satellites  currently  on 
orbit  or  the  design  table,  only  a  handful  have  ISLs  as 
opposed  to  a  bent-pipe  or  demod/remod  approach.  Within 
that  handful,  some  are  GEO  constellations,  some  are  LEO 
constellations  and  a  few  are  in-between  and  will  be  referred 
to  as  MEO  (medium  earth  orbit)  constellations  [6], 

Most  of  the  broadband  constellations  such  as  Spaceway 
(Hughes)  and  V-Stream  (PanAmSat)  are  GEO  and  in  general 
have  power,  mass,  and  data  rate  requirements  that  exceed  the 
range  currently  required  by  an  autonomous  LEO  constella¬ 
tion.  The  MEO  and  LEO  constellations  have  more  similar 
requirements  and  some  relevant  commercial  constellations 
are  listed  in  Table  1.  Most  of  these  constellations  do  not  use 
ISLs,  and  those  that  do  are  further  detailed  in  Table  2. 

It  is  interesting  to  note  that  out  of  the  fixed  constellations  that 
use  ISLs,  only  Iridium  has  actually  made  it  to  launch  and 
operation. 
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TABLE  1 .  Constellations  in  LEO/MEO 


Constellation 

Corporate 

Sponsor 

Orbit,  Altitude, 
Number  of  Sats 

Mass 

ISL 

Operation 

Ellipso 

Boeing,  Lockheed, 
L3  Comm,  Harris 

MEO,  7000km  17  sats 

elliptical,  equatorial 

500  kg 

No 

2002* 

Globalstar 

Qualcomm,  Alca¬ 
tel 

LEO,  1410km,  48  sats 

450kg 

No 

1999 

Iridium 

Motorola 

LEO,  780km,  66  sats 

700kg 

Yes 

1998 

Leo  One 

DaimlerChrysler 
Aero,  Lockheed 

LEO,  950km,  48  sats 

192kg 

No 

2003* 

Orblink 

Orbital  Sciences 

MEO,  9000km,  7  sats 

1360kg 

Yes 

2002* 

Skybridge 

Alcatel 

LEO,  1500km,  80  sats 

1250kg 

No 

2002* 

Teledesic 

ICO,  Motorola, 
Lockheed,  Boeing 

LEO,  700km,  288?  sats 

771kg 

Yes 

2005* 

The  (*)  indicates  operational  date  based  on  projections  in  November  2000. 

TABLE  2.  Constellations  with  ISLs 


Constellation 

ISL 

type 

ISL  band 

ISL  Data 
Rate 

Connection 

Description 

ISL 

Protocols 

Iridium 

RF 

22.55- 

23.55GHz 

25  Mbps 

4  per  satellite 

2  intra-plane 

2  inter-plane 

Motorola  proprietary 
ATM-like  switching 

Orblink 

RF 

65.0- 

71.0GHz 

15  Gbps 

2  per  satellite 

2  intra-plane 

Proprietary  simple 
switching 

Teledesic 

RF 

60GHz 

155  Mbps 

8  per  satellite 

Permanent  and 
dynamic  links 

Teledesic  proprietary 
ATM-like  switching 

Other  Formation-Flying  Constellations 

Commercial  LEO  constellations  are  not  the  best  comparison 
to  an  autonomous  formation-flying  constellation,  but  it  is 
interesting  to  note  that  most  do  not  use  ISLs,  and  of  those 
that  do,  it  is  clear  from  the  above  table  that  there  is  no  stan¬ 
dard  non-proprietary  protocol.  However,  programs  do  exist 
to  develop  autonomous,  formation-flying  constellations  with 
ISLs,  such  as: 

•  NASA’s  New  Millennium  Program  Space  Technology  5 
(NMP  ST5)  with  RF  ISLs. 

•  Surrey  Satellite  Technology  (SSTL)  just  launched  the 
(Surrey  Nanosatellite  Applications  Platform)  SNAP-1 
and  Tsinghua-1  with  RF  ISLs  [6],  [7], 


•  TechSat  21  (AFOSR)  autonomous  cluster  of  formation¬ 
flying  microsatellites  that  operate  cooperatively  to  per¬ 
form  the  function  of  a  larger,  single  satellite.  The  satel¬ 
lites  will  share  data  processing,  payload,  and  mission 
functions  via  RF  ISLs. 

The  NMP  ST5,  SNAP-1,  and  TechSat  21  programs  are  dis¬ 
cussed  in  detail  in  Section  4  because  they  use  RF  ISLs  for 
formation-flying  constellations  and  are  similar  enough  to 
make  a  comparison  of  their  lower  layer  protocol  choices. 

2.0  Brief  Networking  Overview 

This  section  considers  standard  lower  layer  protocols  or  pro¬ 
tocol  combinations  for  use  with  ISLs  on  an  autonomous  for¬ 
mation-flying  constellation.  A  brief  overview  of  the  OSI 
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Manages  user  interface  to  network.  File  access  and 
transfer,  virtual  terminal.  Application  Programming 

Format  conversion,  data  encryption,  compression  and 
expansion. 

Establishes,  maintains  and  synchronizes  dialog  between 
communicating  applications  on  remote  computers. 

Sequencing,  acknowledgment,  flow  control.  Message 
multiplexing.  Fragmentation  and  reassembly. 

Creates  and  routes  packets  (also  called  datagrams).  Net- 
work-wide  logical  addressing. 

Creates  frames,  encapsulates  packets  or  data.  Physical 
address  management.  Error  checking  /  retransmission. 

Transmits  a  bit  stream  that  meets  physical  and  electrical 
interface  requirements  between  user  and  network 

Figure  3:  The  OSI  reference  model.  Although  current  communication  networks  do  not  explicitly  follow  this 
model,  it  is  a  good  reference  for  understanding  what  is  needed  to  make  communication  work.  This  paper  is  prima¬ 
rily  concerned  with  the  functions  of  the  unshaded  lower  layers  in  this  figure. 


Application  Layer 
(Messages) 

Presentation 
(Format  of  Data) 


Session 

(Dialog  Btwn  Apps) 

Transport 

(Segments) 

Network 

(Packets,  Datagrams) 

Data  Link 
(Frames) 


Physical  Layer 
(Bits) 


model  and  description  of  lower  layer  functionality  is  fol¬ 
lowed  by  a  discussion  of  the  protocols  [10], 

The  OSI  Reference  Model 

The  ISO  (International  Standards  Organization)  created  the 
OSI  model  to  define  a  common  way  to  connect  processes.  It 
is  not  necessarily  a  followed  model  in  communication  net¬ 
works,  but  it  serves  well  as  a  basic  guide  for  what  needs  to 
happen  in  order  for  communication  to  be  successful.  The 
OSI  model  has  seven  layers  and  is  outlined  in  Figure  3. 

Lower  Layer  Functionality 

The  lower  three  layers  of  the  OSI  model,  the  network,  data 
link,  and  physical  layers,  are  of  primary  concern  in  this 
paper,  since  they  have  the  largest  role  to  play  when  it  comes 
to  reliable  and  efficient  communication  via  ISL.  Many  of  the 
standard  protocols  such  as  X.25  /  LAP-B,  ATM,  TCP/IP,  and 
IEEE  802.11  cover  all  or  parts  of  these  three  layers  within 
their  protocol  definitions,  and  the  boundaries  between  these 
layers  get  blurred.  It  is  simpler  to  group  the  three  lower  lay¬ 
ers  together  when  attempting  to  compare  protocol  stacks  for 
ISLs.  The  next  section  briefly  covers  some  important  consid¬ 
erations  of  lower  layer  functionality  such  as  connection-ori¬ 
ented  vs.  connectionless,  error  control,  flow  control,  the  role 
of  the  LLC  (logical  link  control)  and  MAC  sublayers,  the 
space  channel  environment  before  going  through  the  previ¬ 
ously  listed  protocols  in  further  detail.  The  X.25/LAP-B  and 
IEEE  802. 1 1  protocols  are  covered  in  more  depth  than  ATM 
and  TCP/IP  as  they  are  better  fits  for  an  autonomous  forma¬ 
tion-flying  constellation. 


Logical  Link  Control  and  Media  Access  Control 

Logical  link  control  (LLC)  is  a  subclass  of  HDLC  (high  level 
data  link  control) 1  that  is  often  used  as  the  link  layer  protocol 
in  local  area  networks  (LANs).  LANs  typically  have  rela¬ 
tively  short,  low  BER  links  that  operate  at  high  bit  rates. 
Errors  are  relatively  infrequent  and  the  round  trip  time  (RTT) 
is  fast.  It  is  acceptable  for  these  networks  to  operate  in  con¬ 
nectionless,  best-try  mode  where  all  retransmission  and  flow 
control  functions,  if  needed,  are  left  to  a  higher  protocol 
layer.  LLC  can  be  used  whenever  error  detection,  correction, 
and  sequencing  are  either  unnecessary  or  implemented  by  a 
higher  layer  and  do  not  need  to  be  replicated  in  the  lower 
layers.  LLC  is  used  to  initiate  transfer  with  minimum  over¬ 
head  (each  additional  layer  adds  headers  with  bits  in  addition 
to  the  information  to  be  transferred).  If  run  in  a  connection- 
oriented  mode  instead,  LLC  is  similar  to  HDLC  except  fram¬ 
ing  and  error  detection  are  done  in  the  MAC  sublayer.  As 
shown  in  Figure  4,  the  MAC  layer  controls  resource  sharing, 
collision  avoidance,  and  interface  with  the  physical  layer. 


1 .  To  help  clarify,  a  connection-oriented  LLC  is  most  similar  to 
IEEE  802.2,  the  IEEE  version  of  HDLC.  HDLC  was  originally 
called  SDLC  by  IBM,  and  renamed  HDLC  when  ISO  made  a 
standard  out  of  it.  There  is  also  the  ITU-T  version  of  HDLC 
called  link  access  protocol,  or  LAP,  and  balanced  mode  is  LAP- 
B.  IEEE  802.3  is  a  MAC  layer  for  bus  networks,  802.4  is  a  MAC 
layer  for  token  bus  networks,  and  802.5  is  a  MAC  layer  for 
token  ring  networks.  IEEE  802.1 1  is  the  MAC  and  physical  lay¬ 
ers  for  a  wireless  network  and  is  discussed  in  further  detail  later 
in  this  paper. 
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Data  Link  Layer 

LLC 

Data  Link 

MAC 

MAC 

Physical  Layer 

Physical 

Physical  Layer 

Figure  4a:  In  a  low  BER  and  high  bit  rate  LAN 
such  as  an  Ethernet,  often  the  data  link  layer 
has  LLC  and  MAC  sublayers.  The  LLC  is  typi¬ 
cally  connectionless  to  avoid  setup  overhead, 
and  the  MAC  ensures  that  the  link  is  used 
fairly,  as  well  as  interfacing  with  the  physical 
layer. 

Causes  of  Error  in  the  Space  Channel 

There  are  several  different  kinds  of  error  that  need  to  be  con¬ 
sidered  and  corrected  for  in  order  to  ensure  the  desired  BER 
and  positioning  accuracy  specified  for  an  autonomous  con¬ 
stellation.  The  first  kind  are  bit  errors.  Single  and  double  bit 
errors  are  usually  simple  to  correct  for  using  CRC  codes. 
However,  burst  errors,  where  many  bits  are  corrupted  at 
once,  may  not  be  corrected  by  CRC  codes  and  occur  more 
frequently  than  single  bit  errors.  Depending  on  the  burst 
length,  FEC  should  be  able  to  help  with  recovery  and  avoid 
retransmissions.  Bit  slips  may  occur,  where  bits  are  lost  due 
to  variations  in  the  respective  clock  rates  of  the  transmitter 
and  receiver.  There  is  also  the  possibility  that  an  entire 
packet  is  lost  due  to  incorrect  addressing,  or  hardware  error 
because  of  electrical  interference  or  thermal  noise.  In  this 
case,  it  is  necessary  to  either  retransmit  or  ignore  the  lost 
packet.  The  possibility  of  link  failure,  due  to  a  damaged  or 
out  of  range  spacecraft,  also  must  be  designed  for.  Space  link 
designs  also  have  to  consider  variable  RTTs,  increased  noise 
or  bursts  of  noise,  limited  bandwidth,  single  event  upsets, 
spacecraft  antenna  obscurations,  limited  processing  power, 
program  memory,  and  data  buffering,  and  sometimes  the  for¬ 
ward  and  return  links  are  not  symmetric  [1],  [11]. 

3.0  Existing  Lower  Layer  Open  Protocols 

HDLC  and  X.25 

The  high-level  data  link  control 
(HDLC)  protocol  is  designed  for  the 
data  link  layer,  to  perform  synchro¬ 
nous  or  asynchronous,  code-transpar¬ 
ent  transmission.  It  has  been  used 
primarily  for  higher  bit  rate,  long  range 
links  such  as  ground-space  satellite 
links  or  multiplexed  circuit  networks. 

The  X.25  packet-switched  network 
layer  protocol  runs  on  a  data  link  layer 


Figure  4b:  In  a  multiple  access  system  such  as  a 
wireless  network,  a  MAC  layer  is  implemented 
to  control  shared  access  of  the  communications 
medium,  collision  avoidance  between  users,  and 
to  interface  with  the  physical  layer  such  as  in 
IEEE802.il. 


called  LAP-B  (balanced  link  access  procedure)  that  is  based 
on  the  asynchronous  balanced  mode  (ABM)  of  HDLC  [12], 
[13]. 

In  addition  to  ABM,  there  are  two  other  modes  of  HDLC, 
normal  response  mode  (NRM)  and  asynchronous  response 
mode  (ARM).  NRM  involves  a  master-slave  relationship 
between  users,  the  master  commands  and  the  slave(s) 
respond.  ARM  also  uses  a  master-slave  relationship,  but  the 
slaves  are  effectively  allowed  to  talk  without  being  spoken  to 
first.  ABM  is  the  democratic  process  where  each  user  has  an 
equal  status  and  may  both  command  or  respond.  There  are 
also  three  non-operational  modes  of  HDLC  that  deal  with 
disconnecting  and  initialization. 

HDLC  uses  a  flag  to  signal  the  start  and  end  of  a  frame 
(01111110)  and  bit-stuffing  to  avoid  a  repeat  of  that 
sequence  in  the  rest  of  the  frame.  HDLC  uses  continuous  RQ 
with  reject  (go-back-n),  selective  reject,  and  multi-selective 
reject  options.  The  information  to  be  sent  is  encapsulated  in 
a  variable  length  frame  called  an  I-frame.  HDLC  can  also 
use  the  I-frame  to  piggyback  acknowledgments  in  the  other 
direction  for  its  RQ  functions.  HDLC  uses  unnumbered 
frames  (U-frames)  to  set  up  and  tear  down  a  link,  and  super¬ 
visory  frames  (S-frames)  for  error  and  flow  control.  Recall 
also  that  HDLC  uses  CRC-CCITT  as  a  frame  check 
sequence  (FCS)  for  error  checking.  The  send  window  of 
HDLC  has  been  extended  from  3  bits  (can  send  7  frames  at  a 
time)  to  7  bits  (can  send  127)  for  long  range  links.  In  gen¬ 
eral,  HDLC  assumes  a  fairly  reliable  link  and  focuses  more 
on  flow  control  than  error  control. 

LAP-B  is  used  to  control  I-frames  being  sent  across  a 
packet-switched  network,  such  as  an  X.25  network.  As  men¬ 
tioned  previously,  LAP-B  is  HDLC  ABM,  and  treats  all  I- 
frames  as  though  they  were  command  frames.  LAP-B  could 
not  handle  multiple  physical  links  until  the  addition  of  the 
multilink  procedure  (MLP)  extension.  MLP  treats  a  set  of 
single  link  procedures  as  though  they  were  a  pool  of  links  to 
transfer  user  frames  over.  It  has  its  own  sequence  numbers. 
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Figure5:  Possible  lower  layer  protocol  stacks  for  an  ISL,  taken  from  the  pool  of  existing  commercial 
standards.  IEEE  802.2  is  the  IEEE  modified  version  of  HDLC. 


and  if  a  link  goes  down,  it  will  simply  continue  using  the 
reduced  set  of  links  in  its  pool. 

The  ITU-T  X.25  standard  specifies  X.21  at  the  physical  layer 
and  LAP-B  at  the  data  link  layer.  X.25  functions  primarily  at 
the  network  layer.  The  basic  strategy  behind  X.25  is  to  allo¬ 
cate  buffer  space  to  a  “virtual  circuit”  on  initialization,  then 
use  the  sliding  window  algorithm  for  flow  control  to  keep  the 
sender  from  overrunning  the  allocated  buffers.  The  initial  set 
up  of  the  virtual  circuit  can  be  rejected  by  the  sender  if  they 
know  that  there  won’t  be  enough  buffers  allocated  to  them.  If 
this  happens,  or  if  a  virtual  circuit  cannot  be  set  up  (due  to 
heavy  loading)  then  a  clear-request  control  packet  goes  back 
to  the  sender,  explaining  why  a  connection  could  not  be 
established. 

X.25  and  LAP-B  can  certainly  work  over  intersatellite  links 
for  an  autonomous  formation-flying  constellation,  and  there 
currently  are  versions  of  HDLC  being  flown  on  some  con¬ 
stellations  designed  with  ISLs  (such  as  SNAP-1).  The  ques¬ 
tion  is  whether  or  not  there  will  ever  be  a  common 
implementation  widely  used  enough  that  it  will  be  standard 
when  the  goal  is  to  have  different  kinds  of  satellites  from  dif¬ 
ferent  clusters  or  even  missions  easily  interact,  or  whether  a 
protocol  designed  specifically  for  intersatellite  or  wireless 
links  would  work  better. 

TCP/IP 

TCP/IP  is  a  two-protocol  stack  that  has 
taken  over  30  years  to  evolve.  The  net¬ 
work  layer  protocol  is  called  the  Inter¬ 
net  Protocol  (IP)  and  the  transport 
layer  is  called  Transport  Control  Proto¬ 
col  (TCP).  The  two  protocols  are  fairly 
intuitive  and  public  domain  -  there  are 
no  licensing  fees  for  using  them.  The 
ISO  has  created  standards  based  on 
them,  however  [14], 

TCP/IP 

The  primary  purpose  of  the  TCP/IP 
combination  was  to  build  an  intercon¬ 
nection  of  networks  that  provided  worldwide  information 


transfer.  Another  goal  was  not  only  to  interconnect  networks 
with  the  same  or  compatible  architectures,  but  to  connect 
networks  that  were  physically  different. 

In  TCP/IP  the  transport  layer  is  providing  the  reliable  end-to- 
end  data  transfer,  and  TCP  is  connection-oriented  even 
though  its  IP  is  connectionless.  IP  can  run  over  X.25,  ATM, 
IEEE  802.2  and  a  number  of  other  lower  layers.  It  has  been 
said  that  IP  can  run  over  two  tin  cans  and  a  piece  of  string 
[8]. 

Although  the  TCP/IP  combination  is  in  fact  a  reliable  com¬ 
munication  protocol  stack,  it  is  intended  to  connect  and  run 
over  many  different  physical  networks  with  their  own  exist¬ 
ing  lower  layer  protocols.  Here  it  is  not  currently  considered 
as  a  stand-alone  candidate  lower  layer  protocol  stack  for  use 
in  an  autonomous  constellation  in  this  paper,  but  it  may  be 
considered  at  the  internetworking  level  for  a  more  advanced 
formation-flying  constellation. 

ATM 

Asynchronous  Transfer  Mode 
(ATM),  or  cell-switching,  is 
used  primarily  for  broadband 
multiservice  networks  and  ser¬ 
vices  such  as  voice,  images, 
data,  video,  and  videoconfer¬ 
encing.  ATM  uses  a  packet 
transfer  mode  based  on  asyn¬ 
chronous  time  division  multi¬ 
plexing.  User  information  is 
transported  in  fixed-length 
blocks,  called  ATM  cells.  Each 
cell  is  48  bytes  long  plus  5  bytes 
of  header  for  a  total  of  53  bytes.  A  cell  is  a  hybrid  of  digi¬ 
tized  voice  transmission  slots  and  variable  length,  multi¬ 
plexed  data  frames.  It  is  much  easier  to  implement  switches 
and  hardware  for  fixed  length  cells,  since  everything  is  uni¬ 
form.  No  error  control  is  performed  on  cells,  and  no 
sequence  numbers  are  required  for  retransmission  [8],  [9], 
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Figure  6:  HDLC  Standard  /  Extended  frame  format  [13] 


With  ATM,  it  is  not  simple  to  implement  things  like  broad¬ 
cast  or  multicast  due  to  its  connection-oriented  and  switched 
nature.  It  does  not  behave  the  same  as  a  shared-media  LAN. 
This  is  currently  still  a  problem  and  attempts  at  resolving  it 
involve  either  a  revision  of  the  protocols  or  developing  an 
ATM  LAN  “emulation.”  For  this  reason,  ATM  will  not  be 
further  discussed  in  this  paper,  since  simple  use  of  broadcast 
and  multicast  methods  is  necessary  for  an  autonomous  con¬ 
stellation. 

IEEE802.il 

Wireless  LANs  are  becoming  more 
popular  in  the  US  and  Europe,  and 
as  demand  for  products  has  grown, 
standards  have  been  developed  to 
ensure  that  they  are  interoperable. 

The  US  wireless  LAN  standard  is 
known  as  IEEE  802.11  [5],  [15]. 

IEEE  802.11  allows  for  three  differ¬ 
ent  kinds  of  physical  layers,  includ¬ 
ing  direct  sequence  spread  spectrum 
(DSSS)  and  frequency  hopping 
spread  spectrum  (FHSS)  which  were  described  earlier.  The 
third  kind  of  physical  layer  is  the  infrared.  Infrared  is  not 
considered  here  due  to  range  restrictions.  It  is  also  seldom 
used  for  wireless  terrestrial  LANs  for  the  same  reason. 

FHSS  breaks  up  the  total  bandwidth  into  frequency  channels 
and  takes  pseudorandom  “hops”  from  channel  to  channel 
after  a  predetermined  time  interval  has  elapsed.  For  802.11, 
the  time  interval  is  <  300ms.  As  mentioned  earlier,  this  alle¬ 
viates  any  collision  avoidance  issues  as  the  signal  is  trans¬ 
mitted  on  any  one  given  frequency  only  for  a  very  short 
amount  of  time.  The  channel  bandwidth  is  1MHz,  and  FHSS 
avoids  repeat  use  of  a  channel  if  at  all  possible.  FHSS  uses 
Gaussian  FSK  (frequency  shift  keying)  to  modulate  the  sig¬ 
nals.  FHSS  operates  in  either  a  1Mbps  or  a  2Mbps  mode. 

Instead  of  dividing  the  bandwidth  into  channels,  DSSS 
spreads  the  signal  across  the  entire  bandwidth,  which 
increases  bandwidth  utilization.  The  signal  modulation  is 
based  on  PSK  (phase  shift  keying)  and  is  fed  to  a  spreader 
chip  which  then  multiples  the  signal  with  a  pseudorandom 
signal  called  a  chip  sequence,  which  is  based  on  the  eleven- 
chip  Barker  sequence.  IEEE  802.11  specifies  two  data  rates 


for  DSSS,  1  Mbps  using  BPSK  (binary  PSK)  or  2  Mbps 
using  QPSK  (quadrature  PSK). 

In  terrestrial  systems,  DSSS  works  reliably  at  greater  dis¬ 
tances  than  FHSS  (150m  vs.  250m  for  a  reliable  link  at 
1Mbps)  but  keep  in  mind  these  terrestrial  transmitters  are 
operating  at  very  low  power,  for  example  30mW  is  used  for 
the  802.11  compatible  WaveLAN  card.  The  US  802.11  spec¬ 
ifies  a  maximum  RF  power  level  of  1W.  How  well  802.11 
would  scale  up  to  the  10km  range  required  by  an  autono¬ 
mous  constellation  has  not  yet  been  determined. 

The  MAC  layer  for  802. 1 1  has  frames  with  sequence  control 
and  retry  fields  to  help  minimize  interference  since  the  RF 
components  are  omnidirectional.  The  sequence  control  fields 
work  with  type,  subtype,  duration,  and  fragmentation  fields 
that  are  concerned  with  reliability.  Carrier  sense  multiple 
access  with  collision  avoidance  (CSMA/CA)  is  used  to  avoid 
potential  confusion  between  detecting  collisions  and  noise. 
The  MAC  layer  also  handles  acknowledgments  in  802.11. 
Because  there  is  an  interframe  spacing  period  of  50  micro¬ 
seconds  for  all  users,  the  receiver  can  do  a  quick  32-bit  CRC 
check  and  send  back  an  ACK  in  10  microseconds,  while  the 
medium  is  still  free.  The  MAC  layer  also  supports  “hidden” 
users  that  are  not  within  range  of  their  intended  recipient  but 
can  see  someone  in  between. 

IEEE  802.11  uses  fragmentation  to  deal  with  high  RF  inter¬ 
ference  conditions  to  allow  faster  sending  and  receiving. 
Regular  beacons  (~  everylOO  milliseconds)  are  sent  to  every 
user  in  range  that  includes  a  timestamp,  traffic  map,  and  sup¬ 
ported  data  rates. 

IEEE  802.1 1  has  many  features  that  the  autonomous  constel¬ 
lations  could  make  good  use  of,  but  it  remains  to  be  deter¬ 
mined  whether  or  not  IEEE  802.11  can  adequately  scale  up 
to  the  desired  power  and  range  requirements.  The  802.11 
standard  specifies  operation  in  the  ISM  unlicensed  2.4  GHz 
band,  in  which  the  FCC  limits  output  power  to  1  Watt.  The 
802.1 1  MAC  protocol  can  probably  be  used,  but  the  physical 
layer  would  at  least  need  to  be  adapted  to  a  different  fre¬ 
quency  and  to  be  compliant  in  transmitting  at  higher  power 
levels. 

4.0  CCSDS  Lower  Layer  Protocols 

CCSDS  Proximity-1 
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Figure  7:  The  CCSDS  Proximity-1  protocol  stack  [11]. 


The  CCSDS  Proximity- 1  protocol  is 
based  on  the  CCSDS  telecommand 
frame  and  is  intended  for  cross-support 
purposes  on  proximity  links.  Proximity 
links  are  defined  as  being  short  range,  bi¬ 
directional,  fixed  or  mobile  radio  links  to 
communicate  among  landers,  rovers, 
orbiting  constellations,  and  orbiting 
relays.  Proximity  links  have  short  time 
delays,  moderate  (not  weak)  signals,  and 
short,  independent  sessions  [11], [16]. 

With  respect  to  the  OSI  Model,  Proximity- 1  (Prox-1)  func¬ 
tionality  corresponds  to  the  Physical  and  Data  Link  layers. 
However,  the  Prox- 1  data  link  functionality  is  broken  up  into 
not  two,  but  four  sublayers,  the  frame  sublayer,  MAC  sub¬ 
layer,  data  services  sublayer,  and  an  Input/Output  sublayer  as 
shown  in  Figure  7. 

Prox-1  supports  both  synchronous  and  asynchronous  modes 
of  communication.  For  synchronous  links,  the  Prox-1  frame 
is  fixed  length,  and  frames  are  transmitted  continuously  for 
the  duration  of  the  session.  The  fixed  length  frames  are  use¬ 
ful  in  weaker  signal  environments  as  FEC  block-coding 
(Reed  Solomon)  can  then  be  used  for  the  added  coding  gain. 
Asynchronous  links  have  variable-length  frames,  and  are 
intended  for  use  on  links  with  short  time  delays,  moderate 
signal  strength,  and  short  session  duration.  Prox-1  also  uses 
the  virtual  channel  approach  to  communication  links,  how¬ 
ever,  fixed  and  variable  length  frames  cannot  be  multiplexed 
on  the  same  channel. 

Two  types  of  data  services  are  provided  -  one  that  accepts 
and  delivers  packets,  and  one  that  accepts  and  delivers  user- 
defined  data.  In  the  first,  packets  that  are  delivered  are  of  a 
standard  format,  such  as  CCSDS  source  packets,  SCPS 
packets,  IP  packets,  encapsulation  packets,  etc.  In  the  sec¬ 
ond,  the  data  transmitted  does  not  have  to  be  recognized  by 
the  Prox-1  protocol  as  a  standard  packet,  but  just  the  user’s 
data. 


There  are  also  two  grades  of  service  (sequence  controlled 
and  expedited)  that  determine  how  reliably  service  data  units 
(SDUs)  are  sent.  One  is  more  connection-oriented,  and  the 
other  is  essentially  connectionless.  Each  grade  must  be 
accessed  through  their  own  service  access  point  (SAP). 

The  Sequence  Controlled  service  grade  ensures  that  data  is 
reliably  transferred  across  the  space  link  and  delivered  in 
order,  without  gaps,  errors,  or  duplications  within  a  commu¬ 
nication  session.  Making  sure  there  are  no  duplications 
between  the  termination  and  initiation  of  a  session  is  a 
responsibility  that  is  left  to  a  higher  layer.  The  Sequence 
Controlled  service  is  based  on  a  go-back-n  type  of  ARQ.  The 
Prox-1  version  of  an  acknowledgment,  or  “standard  report” 
from  the  receiving  end  to  the  sending  end  is  called  a  proxim¬ 
ity  link  control  word  (PLCW). 

Expedited  service  is  essentially  connectionless  and  intended 
for  use  either  with  higher  level  protocols  that  provide  their 
own  retransmission  features,  or  in  exigent  circumstances 
such  as  spacecraft  recovery.  Expedited  SDUs  are  sent  with¬ 
out  ARQ,  and  they  are  sent  independently  of  Sequence  Con¬ 
trolled  SDUs.  When  using  expedited  service,  it  is  possible  to 
deliver  portions  of  SDUs  that  are  greater  than  the  maximum 
frame  size  allowed  for  the  link. 

In  the  most  recent  version  of  the  CCSDS  Red  Book  for  Prox- 
1,  Issue  2,  the  physical  layer  focuses  on  use  on  Mars,  since 
its  first  implementation  was  on  Mars  Observer  ‘01.  In  an 
upcoming  version,  there  should  be  an  addendum  that  out¬ 
lines  a  physical  layer  suitable  for  use  on  Earth  with  fre¬ 
quency  bands  near  26GHz  pending  FCC  approval.  Prox-1 
supports  many  data  rates,  currently  between  2kbps  and 
2Mbps.  It  also  allows  for  convolutional  coding  (1/2  con¬ 
straint  length  7  Viterbi)  for  FEC  and  specifies  a  link  with 
BER  <1CT6  for  both  coded  and  uncoded  links.  It  also  allows 
for  Doppler  tracking. 

The  frame  sublayer  accepts  frames  from  higher  layers,  adds 
the  PLCW  data  to  complete  the  frame,  forms  a  status  report 
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and  includes  it  in  the  frame,  determines  the  order  of  trans¬ 
mission,  and  forms  the  proximity  link  transmission  units 
(PLTUs)  to  be  sent.  On  the  receiving  end,  the  frame  layer 
delimits  the  PLTU,  performs  FEC  or  error  detection,  verifies 
that  it  is  error  free,  verifies  that  it  was  sent  by  an  acknowl¬ 
edged  user,  and  routes  it  to  a  higher  layer. 

The  frame  structure  includes  an  attached  synchronization 
marker  (ASM)  that  is  24  bits  long  when  only  CRC  is  used 
for  error  detection,  and  32  bits  long  when  Reed  Solomon 
FEC  is  used.  Since  Reed  Solomon  codes  are  block  codes, 
they  can  only  be  used  with  fixed  length  frames.  The  Prox-1 
32-bit  CRC  can  be  used  with  both  fixed  and  variable  length 
frames. 

The  MAC  sublayer  is  responsible  for  establishing,  maintain¬ 
ing,  and  terminating  a  session.  Prox-1  defines  away  channel 
contention  for  single  links  by  using  a  hailing  frequency  and  a 
check  before  allocating  channel  resources.  With  multiple 
links,  a  collision  avoidance  approach  is  taken,  where  the 
hailing  transmit  time  is  staggered  to  try  to  avoid  contention. 

The  data  service  sublayer  exists  to  control  the  order  of  the 
user  data  to  be  transferred,  including  commands  (directives) 
that  are  to  be  transmitted  within  one  session.  Expedited  ser¬ 
vice  ensures  delivery  of  frames  in  the  order  that  they  are 
received  from  a  higher  layer,  but  there  is  no  error  checking. 
The  data  service  sublayer  is  responsible  for  ensuring  the  reli¬ 
ability  of  the  sequence  controlled  data. 

The  Input/Output  sublayer  will  determine  how  to  integrate 
received  packets  into  the  frames  with  functions  such  as  seg¬ 
menting,  etc.  to  interface  with  the  lower  sublayer  using  two 
queues,  one  for  expedited  and  one  for  sequence  controlled. 

The  Prox-1  protocol  seems  like  a  very  good  fit  to  the  needs 
of  the  lower  layers  in  an  autonomous  constellation,  which 
isn’t  surprising  since  it  was  specifically  designed  for  such 
ISLs.  The  protocol  has  not  yet  become  an  approved  CCSDS 
standard  but  is  currently  in  stable  Red  Book  phase.  It  is  the 
only  protocol  being  considered  for  use  by  spacecraft 
involved  in  the  Mars  Network,  and  is  the  primary  protocol 
being  considered  by  the  New  Millennium  Program  ST5  con¬ 
stellation,  which  is  discussed  in  Section  5. 

CCSDS  SCPS 

The  SCPS  protocol  stack  is  the  “space  equivalent”  of  TCP/IP 
and  was  designed  with  the  goal  of  extending  internet  connec¬ 
tivity  into  space.  In  addition  to  the  error-protected, 
sequenced  data  streams  with  real  time  acquisition  and  quick 
look  analysis  of  the  standard  CCSDS  protocols,  it  also  sup¬ 
ports  automatic,  real-time  retransmission  to  provide  com¬ 
plete  and  best-effort  data  streams  and  reliable  file  transfer. 
The  SCPS  protocol  stack  begins  at  the  network  layer,  as  does 
TCP/IP,  so  although  it  remains  a  contender  as  a  higher  layer 
protocol,  it  is  not  a  complete  lower  layer  protocol.  The  SCPS 
Network  Protocol  (SCPS-NP)  went  CCSDS  Blue  Book  in 


May  1999,  and  as  mentioned  in  the  previous  section,  can  run 
over  Prox-1  [17]. 

CCSDS  AOS 

CCSDS  extended  its  previous  space/ground  and  ground/ 
space  link  recommendations  to  reflect  the  needs  of  the 
Advanced  Orbiting  Systems  (AOS)  of  the  1990s  and  beyond, 
providing  a  more  diverse  and  flexible  set  of  data  handling 
services.  These  services  are  intended  for  uses  such  as 
manned  and  man-tended  space  stations,  unmanned  space 
platforms,  free-flying  spacecraft,  and  any  other  spacecraft 
needing  services  to  concurrently  transmit  multiple  digital 
data  types  such  as  audio  and  video.  However,  the  AOS  proto¬ 
cols  are  not  intended  for  space-space  links,  as  the  Prox-1 
protocol  is  [18], 

5.0  Autonomous  Constellations  and  ISLs 

New  Millennium  Program  ST5 

NASA’s  Space  Technology  5  (ST5)  mission,  called  “The 
Nanosat  Constellation  Trailblazer”  is  the  fourth  deep  space 
mission  in  NASA’s  New  Millennium  Program.  ST5  is  slated 
as  a  secondary  launch  in  2003  and  plans  to  fly  a  constellation 
of  three  nanosatellites  (21.5kg  each)  at  about  a  200km  by 
36,000km  altitude  to  monitor  the  magnetosphere. 

Like  TechSat  21,  the  spacecraft  will  be  used  to  test  the  “vir¬ 
tual  satellite”  concept  of  operating  a  constellation  as  a  single 
system.  The  ST5  satellites  will  attempt  to  perform  coordi¬ 
nated  movements,  communication,  and  scientific  observa¬ 
tions  of  the  magnetosphere  as  if  they  were  a  single  larger 
spacecraft.  This  includes  the  goal  of  having  the  spacecraft 
autonomously  stay  in  contact  with  each  other,  share  informa¬ 
tion,  and  reconfiguring  onboard  instruments  and  systems  to 
behave  as  a  single  unit.  The  mission  is  managed  by  NASA’s 
Goddard  Space  Flight  Center  (GSFC)  in  Greenbelt,  Mary¬ 
land. 

JPL  is  working  on  the  miniature  spacecraft  communications 
system  that  provides  the  capability  to  communicate  between 
spacecraft  and  determine  the  positions  of  spacecraft  relative 
to  each  other  and  the  ground  using  GPS,  which  is  very  simi¬ 
lar  to  the  TechSat  21  ISL  communications  approach.  The 
data  rate  for  ST5  will  be  lower,  however,  because  it  does  not 
currently  include  transferring  a  great  amount  of  payload 
data.  For  a  scenario  where  data  is  transferred  in  order  to  do 
parallel  processing  using  constellation  resources,  the  data 
rate  would  significantly  increase. 

With  respect  to  a  lower  layer  protocol  selection  for  this 
project,  sources  at  JPL  report  that  they  started  out  not  con¬ 
sidering  any  options  other  than  the  CCSDS  Proximity- 1 
specification.  This  was  chosen  due  to  some  similar  work 
being  done  at  JPL  on  the  Mars  Network  cross-links  where 
Proximity- 1  is  required.  They  have  recently  started  consider- 
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Figure  8:  Artist’s  conception  of  ST5 


ing  using  the  MAC  layer  of  IEEE  802. 11,  but  have  not  as  of 
the  writing  of  this  paper  done  a  thorough  evaluation  on 
it[  19] . 

The  data  rate  that  ST5  will  be  using  is  low,  only  about  1kbps 
at  the  moment,  and  they  are  looking  at  using  the  S  frequency 
band.  The  spacecraft  are  power  limited,  with  the  transceiver 
at  less  than  10W,  including  the  baseband  processor  and  RF 
power  electronics.  The  maximum  ranges  they  are  designing 
to  vary  between  100  to  10,000km,  depending  on  mission 
configuration  and  life-cycle. 

SSTL  SNAP-1  and  Tsinghua-1 

The  Surrey  Nanosatellite  Applications  Platform  (SNAP)  is  a 
flexible  commercial  6.5kg  nanosatellite  platform  aimed  at 
providing  access  to  space  at  a  reasonable  cost.  SNAP  func¬ 
tionality  includes  formation  flying,  inter-spacecraft  commu¬ 
nications,  on-board  navigation,  propulsion,  and  machine 
vision  for  remote  inspection.  The  Tsinghua-1  microsatellite 
is  a  joint  venture  between  Tsinghua  University  in  China  and 
SSTL.  Tsinghua-1  carries  a  camera  capable  of  39  meter  res¬ 
olution  images  in  three  spectral  bands  and  is  designed  to  be  a 
prototype  for  a  future  Disaster  Monitoring  Constellation 
(DMC)  proposed  by  SSTL,  a  network  of  five  small  satellites 
to  monitor  natural  and  man-made  disasters. 

Both  SNAP-1  and  Tsinghua-1  were  launched  from  the 
Plesetsk  Cosmodrome  into  a  650km  sun-synchronous  orbit 
on  June  28,  2000.  The  recent  update  is  that  most  of  the  sys¬ 
tems  have  already  been  tested  successfully,  although  there  is 
no  itemized  list  currently  available,  and  it  is  not  known 
whether  the  ISL  has  yet  been  tested  [7]. 

The  primary  goals  of  the  SNAP-1  mission  included  demon¬ 
strating  an  intersatellite  communication  channel  between  the 
two  satellites,  experimenting  with  GPS  ranging  between  the 
two  satellites,  and  demonstrating  formation  flying.  SNAP-1 
is  currently  doing  earth  observing  with  four  sub-miniature 
CMOS  cameras. 


The  SNAP-1  and  Tsinghua-1  ISLs  are  RF,  with  a  9.6kbps 
data  rate.  SNAP-1  uses  an  HDLC  controller  implemented  in 
a  FPGA  for  communication  at  close  range,  as  well  as  for  the 
synchronous  uplink  and  downlink.  The  electrical  power  con¬ 
sumption  of  the  ISL  RF  system  is  on  the  order  of  400  mW. 
There  is  currently  no  goal  for  SNAP-1  to  communicate  with 
any  other  spacecraft  than  Tsinghua-1.  The  GPS  ranging  on 
SNAP-1  will  be  accurate  only  to  about  15  meters. 

TechSat  21 

As  described  earlier,  TechSat  21  is  the  autonomous  forma- 


Figure  9:  The  Surrey  SNAP-1  satellite. 


tion-flying  constellation  being  developed  by  AFOSR  for 
remote  sensing  applications  and  currently  has  a  test  flight 
demo  scheduled  for  2003  and  plans  to  have  an  operational 
cluster  by  2005.  The  microsatellites  will  be  in  close  proxim¬ 
ity  clusters,  with  the  possibility  of  40  clusters  in  orbit  at  a 
time.  One  of  the  goals  of  this  program  is  to  be  able  to  easily 
interchange  single  satellites  and  thus  be  able  to  vary  the 
capabilities  of  the  cluster[20], 

6.0  Summary 

Recap 

First,  a  description  of  ISL  functionality  was  given,  and  it  was 
shown  that  the  ISL  designs  for  current  GEO  and  LEO  broad¬ 
band  or  mobile  communications  networks  are  not  similar 
enough  to  the  requirements  for  an  autonomous  formation¬ 
flying  constellation  that  their  lower  layer  protocols  be  con¬ 
sidered  for  comparison.  This  was  followed  by  a  brief  over¬ 
view  of  the  networking  principles  necessary  to  compare 
lower  layer  protocols  against  each  other.  Then,  a  detailed 
summary  of  existing  and  upcoming  protocol  standards  were 
presented: 

It  was  concluded  that  ATM  did  not  adequately  support  multi¬ 
ple  access,  TCP/IP  and  SCPS  were  too  high  up  the  protocol 
stack  to  be  considered  as  a  lower  layer  protocol,  AOS  was 
not  intended  for  space-space  links,  and  that  the  IEEE  802. 1 1 
physical  layer  would  need  to  be  entirely  revamped  to  meet 
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physical  layer  requirements.  Both  X.25/LAP-B  and  CCSDS- 
Proximity-1  remained  as  possible  options  for  the  ISL  lower 
layer  protocol,  and  the  possibility  of  using  the  IEEE  802.11 
MAC  layer  was  also  acknowledged. 

Three  similar  missions  that  have  been  or  are  being  designed 
were  described.  The  requirements  of  the  NMP  ST5  space¬ 
craft  more  closely  match  those  of  TechSat  21  in  terms  of 
power,  range,  and  multiple  access.  However,  since  all  three 
programs  have  come  to  the  conclusion  that  either  some  ver¬ 
sion  of  HDLC  (SNAP-1)  or  CCSDS  Proximity-1  (ST5) 
should  be  used,  this  paper  will  conclude  with  a  comparison 
of  the  two. 

X.25/LAP-B  vs.  CCSDS  Prox-1 

It  is  evident  that  Proximity- 1  was  designed  specifically  for 
close-range  space-space  links,  where  X.25  was  created 
almost  30  years  ago  with  terrestrial  networks  in  mind.  How¬ 
ever,  there  are  existing  commercial  parts,  experience,  and 
support  for  an  X.25  or  HDLC  system  where  there  are  no 
commercial  parts  or  support  for  Prox-1  yet  available, 
although  that  should  change  as  Prox-1  becomes  an  approved 
CCSDS  standard  (blue  book).  There  have  been  recent  talks 
with  NASA  GSFC  about  manufacturing  chips,  and  Prox-1 
has  been  implemented  already  on  the  Mars  Surveyor  2001 
Orbiter.  Prox-1  has  also  been  baselined  by  ESA  for  the  Mars 
Express  MARESS  transceiver  and  Beagle  II  lander  for  their 
2003  mission.  However,  commercial  parts  are  not  the  same 
as  specific  flight  hardware,  which  would  probably  still  need 
to  be  procured  in  either  case. 

The  HDLC -based  X.25  protocol  depends  on  a  specific  eight- 
bit  sequence  to  determine  the  start  and  end  of  a  frame,  and  to 
ensure  it  is  not  repeated,  it  uses  the  technique  of  bit-stuffing 
on  the  rest  of  the  data.  This  could  be  problematic  given  that 
in  low  SNR  environments,  cycle  slips  can  occur  at  the 
receiver,  which  show  up  as  one  or  more  bit  slips  in  the  data. 
This  could  cause  an  HDLC  frame  to  be  interpreted  as  two 
separate  shorter  frames  or  a  long  frame  could  be  split  into 
two  shorter  frames.  This  should  not  happen  with  Proximity- 
1,  as  there  is  an  attached  synchronization  marker  (ASM)  that 
is  either  24  or  32  bits  long,  depending  whether  block  coding 
is  used  or  not.  This  allows  for  more  reliable  synchronization 
and  advance  knowledge  of  frame  length,  as  the  probability  of 
error  in  the  frame  length  field  is  very  low. 

Recall  that  HDLC  uses  a  16-bit  CRC  check  called  CRC- 
CCITT,  and  from  the  discussion  of  CRC  checks  that  this 
CRC  can  protect  against  all  single,  double,  and  odd  bit  errors 
plus  burst  layers  that  are  shorter  than  the  degree  of  the  poly¬ 
nomial,  which  is  16  in  this  case,  provided  no  other  errors 
occur  within  the  frame.  Prox-l’s  CRC  may  be  able  to  protect 
up  to  32  bit  long  burst  lengths.  The  FEC  option  that  Prox-1 
provides  can  correct  still  more  errors,  possibly  up  to  multiple 
packet  errors.  However,  a  longer  CRC  or  use  of  FEC 
increases  the  amount  of  overhead. 


Prox-1  offers  two  grades  of  service,  one  with  fixed  length 
frames  and  the  other  expedited  with  variable  length  frames. 
All  HDLC  frames  are  variable  length.  This  means  that  no 
block  coding  can  be  used  with  FEC  in  HDLC  to  reduce  the 
bit  error  rate.  If  there  are  ranging  requirements,  for  example 
that  satellite  position  information  be  sent  with  a  bit  error  rate 
less  than  10  ,  then  high  performance  block  codes  such  as 

the  Reed-Solomon  codes  would  be  beneficial  in  attempting 
to  achieve  this,  especially  at  greater  distances  with  lower 
SNR. 

HDLC  uses  modes  -  it  has  three  operational  modes,  the 
mode  of  choice  for  ISLs  being  ABM.  In  addition  it  has  three 
non-operational  modes  for  disconnecting  and  initialization. 
Proximity- 1  is  modeless,  telemetry,  command  and  ranging/ 
timing  services  can  all  take  place  concurrently  without 
scheduling  or  switching  modes  by  mission  operations.  Prox- 
1  was  also  designed  with  the  realization  that  the  forward  and 
return  links  may  not  be  symmetrical,  where  HDLC  was 
designed  for  symmetric  links. 

Added  bonuses  for  Prox-1  include  the  fact  that  since  Prox-1 
can  carry  CCSDS  frames  in  its  packets,  it  should  be  possible 
to  communicate  directly  with  a  CCSDS  ground  station  as 
backup.  Also,  if  it  is  desirable  at  some  point  to  talk  to  other 
autonomous  spacecraft  near  to  the  constellation,  it  would  be 
prudent  to  choose  a  protocol  that  other  agencies  are  likely  to 
use.  CCSDS  is  prevalent  in  ground/space  communications, 
and  Prox-1  will  be  a  CCSDS  standard  that  is  intended  for 
space-space  communication  and  supported  by  both  national 
and  international  agencies.  However,  Prox-1  is  currently  still 
in  Red  Book  stage  and  HDLC  has  decades  of  commercial 
production  and  existing  engineering  expertise,  even  though  it 
was  not  intended  for  use  on  intersatellite  links.  An  experi¬ 
mental  comparison  of  two  similar  implemented  systems 
including  a  cost  estimate  is  needed  to  determine  whether  the 
benefits  built  into  Prox-1  will  outweigh  the  availability  of 
existing  standards  such  as  HDLC  or  IEEE  802.1 1. 
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